-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Support memoryview encoding/decoding as a no-op, calling tobytes() on… #1285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1285 +/- ##
==========================================
+ Coverage 92.45% 92.72% +0.26%
==========================================
Files 19 19
Lines 6415 6444 +29
==========================================
+ Hits 5931 5975 +44
+ Misses 484 469 -15
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions and questions inline below. And two suggestions overall:
It would be nice to add a simple memoryview test going through a pipeline. The changes to Connection.pack_commands aren't tested otherwise as Pipeline is the only thing calling pack_commands().
Further, I'd propose that we subclass memoryview and override its tobytes() to emit a warning. Then we could use that subclass in the test suite instead of the base memoryview. That should hopefully confirm that these optimizations are actually useful.
| value = value.decode(self.encoding, self.encoding_errors) | ||
| "Return a unicode string from the bytes-like representation" | ||
| if (self.decode_responses or force): | ||
| if isinstance(value, memoryview): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you run into a case where you needed this? Are we ever actually decoding memoryview instances?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I ran into a case in the tests where a memoryview gets decoded. I think I got a bit spooked by lines like this and this, but on a closer look those lines shouldn't cause a problem unless the user passes a memoryview kwarg -- and the docs instruct them to pass strings. Maybe it just felt right to make sure that decode(encode(x)) always works, but it seems it's not essential, happy to remove this if you prefer.
|
Thanks for the review! I think most of the changes are straightforward. I like the idea of subclassing Edit: and also testing |
|
This seems ready for another review. To summarize the changes, everything was straightforward except:
I also noticed that the argument length-checking and joining code in |
|
Thanks @Cody-G. This has been merged. |
…ly when decode_responses=True
Pull Request check-list
Please make sure to review and check all of these items:
$ toxpass with this change (including linting)?Description of change
Supports passing memoryviews to redis-py as first outlined in #1265 and discussed further in #1266